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INFRARED DATA ASSOCIATION (IrDA) - NOTICE TO THE TRADE - 


SUMMARY: 


Following is the notice of conditions and understandings upon which this document is made available to 
members and non-members of the Infrared Data Association. 


Availability of Publications, Updates and Notices 

e Full Copyright Claims Must be Honored 

Controlled Distribution Privileges for LDA Members Only 
e Trademarks of IrDA - Prohibitions and Authorized Use 

e¢ No Representation of Third Party Rights 

e Limitation of Liability 


Disclaimer of Warranty 


Product Testing for IrDA Specification Conformance 
IrDA PUBLICATIONS and UPDATES: 


IrDA publications, including notifications, updates, and revisions, are accessed electronically by IrDA 
members in good standing during the course of each year as a benefit of annual IrDA membership. 
Electronic copies are available to the public on the IrDA web site located at irda.org. Requests for 
publications, membership applications or more information should be addressed to: Infrared Data 
Association, P.O. Box 3883, Walnut Creek, California, U.S.A. 94598; or e-mail address: info @irda.org; or 
by calling John LaRoche at (510) 943-6546 or faxing requests to (510) 934-5600. 


COPYRIGHT: 


1. Prohibitions: IrDA claims copyright in all IrDA publications. Any unauthorized reproduction, 
distribution, display or modification, in whole or in part, is strictly prohibited. 


2. Authorized Use: Any authorized use of IrDA publications (in whole or in part) is under 
NONEXCLUSIVE USE LICENSE ONLY. No rights to sublicense, assign or transfer the license are granted 
and any attempt to do so is void. 


TRADEMARKS: 


1. Prohibitions: IrDA claims exclusive rights in its trade names, trademarks, service marks, collective 
membership marks and trademark marks (hereinafter collectively "trademarks"), including but not limited to 
the following trademarks: INFRARED DATA ASSOCIATION (wordmark alone and with IR logo), IrDA 
(acronym mark alone and with IR logo), IR logo, and MEMBER IrDA (wordmark alone and with IR logo). 
Any unauthorized use of IrDA trademarks is strictly prohibited. 


2. Authorized Use: Any authorized use of a IrDA collective membership mark or trademark mark is by 
NONEXCLUSIVE USE LICENSE ONLY. No rights to sublicense, assign or transfer the license are granted 
and any attempt to do so is void. 


NO REPRESENTATION of THIRD PARTY RIGHTS: 
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IrDA makes no representation or warranty whatsoever with regard to ITDA member or third party ownership, 
licensing or infringement/non-infringement of intellectual property rights. Each recipient of IrDA 
publications, whether or not an IrDA member, should seek the independent advice of legal counsel with 
regard to any possible violation of third party rights arising out of the use, attempted use, reproduction, 
distribution or public display of IrDA publications. 


IrDA assumes no obligation or responsibility whatsoever to advise its members or non-members who receive 
or are about to receive IrDA publications of the chance of infringement or violation of any right of an IrDA 
member or third party arising out of the use, attempted use, reproduction, distribution or display of IrDA 
publications. 


LIMITATION of LIABILITY: 


BY ANY ACTUAL OR ATTEMPTED USE, REPRODUCTION, DISTRIBUTION OR PUBLIC DISPLAY 
OF ANY IrDA PUBLICATION, ANY PARTICIPANT IN SUCH REAL OR ATTEMPTED ACTS, 
WHETHER OR NOT A MEMBER OF IrDA, AGREES TO ASSUME ANY AND ALL RISK 
ASSOCIATED WITH SUCH ACTS, INCLUDING BUT NOT LIMITED TO LOST PROFITS, LOST 
SAVINGS, OR OTHER CONSEQUENTIAL, SPECIAL, INCIDENTAL OR PUNITIVE DAMAGES. IrDA 
SHALL HAVE NO LIABILITY WHATSOEVER FOR SUCH ACTS NOR FOR THE CONTENT, 
ACCURACY OR LEVEL OF ISSUE OF AN IrDA PUBLICATION. 


DISCLAIMER of WARRANTY: 


All IrDA publications are provided "AS IS" and without warranty of any kind. IrDA (and each of its 
members, wholly and collectively, hereinafter "ITDA") EXPRESSLY DISCLAIM ALL WARRANTIES, 
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND WARRANTY OF NON- 
INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS. 

IrDA DOES NOT WARRANT THAT ITS PUBLICATIONS WILL MEET YOUR REQUIREMENTS OR 
THAT ANY USE OF A PUBLICATION WILL BE UN-INTERRUPTED OR ERROR FREE, OR THAT 
DEFECTS WILL BE CORRECTED. FURTHERMORE, IrDA DOES NOT WARRANT OR MAKE ANY 
REPRESENTATIONS REGARDING USE OR THE RESULTS OR THE USE OF IrDA PUBLICATIONS 
IN TERMS OF THEIR CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. NO ORAL OR 
WRITTEN PUBLICATION OR ADVICE OF A REPRESENTATIVE (OR MEMBER) OF IrDA SHALL 
CREATE A WARRANTY OR IN ANY WAY INCREASE THE SCOPE OF THIS WARRANTY. 


LIMITED MEDIA WARRANTY: 


IrDA warrants ONLY the media upon which any publication is recorded to be free from defects in materials 
and workmanship under normal use for a period of ninety (90) days from the date of distribution as 
evidenced by the distribution records of IrDA. IrDA's entire liability and recipient's exclusive remedy will be 
replacement of the media not meeting this limited warranty and which is returned to IrDA. IrDA shall have 
no responsibility to replace media damaged by accident, abuse or misapplication. ANY IMPLIED 
WARRANTIES ON THE MEDIA, INCLUDING THE IMPLIED WARRANTIES OF 
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ARE LIMITED IN DURATION 
TO NINETY (90) DAYS FROM THE DATE OF DELIVERY. THIS WARRANTY GIVES YOU 
SPECIFIC LEGAL RIGHTS, AND YOU MAY ALSO HAVE OTHER RIGHTS WHICH VARY FROM 
PLACE TO PLACE. 


COMPLIANCE and GENERAL: 
Membership in IrDA or use of IrDA publications does NOT constitute IrDA compliance. It is the sole 
responsibility of each manufacturer, whether or not an IrDA member, to obtain product compliance in 


accordance with IrDA Specifications. 
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All rights, prohibitions of right, agreements and terms and conditions regarding use of IrDA publications 
and IrDA rules for compliance of products are governed by the laws and regulations of the United States. 
However, each manufacturer is solely responsible for compliance with the import/export laws of the 
countries in which they conduct business. The information contained in this document is provided as is and 
is subject to change without notice. 
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1. Introduction 


1.1. Foreword 


IrTran-P(UInfrared Transfer Picture) is an image communication scheme for a digital camera based on the 
Infrared Communication Standard specification created by IrDA. The IrTran-P specification is to be largely 
used together with the IrDA standard specifications. 


1.2. Scope of IrTran-P Standard 


IrTran-P is placed on the upper layer of IrSIR, InLAP, IrLMP, TinyTP and IrCOMM which is already 
established as IrDA standard specifications. SCEP (Simple Command Execute Protocol) and a bFTP 
(Binary File Transfer Protocol) are necessary for exchanging an image between devices and mutually 
exchanging properties of the devices. An image format (file) called UPF (Uni Picture Format) is exchanged 
on such an entity(UPF is image format out of the category of IrDA, and will be treated as an appendix.). 
IrTran-P is a generic name given to all of these components. 


This section is written to clarify and position the respective standards adopted by IrTran-P, in what context 
the standards are adopted, and to facilitate understanding of the reason for adoption as well. As for 
technical data on SCEP, bFTP and UPF, please refer to the sections individually written for SCEP, bFTP and 
UPF in the later part of this document. 


UPF(Uni Picture Format) 
bFTP (binary File Transfer Protocol) 


(Command definition) 


SCEP (Simple Command Execute Protocol) 


(Connection management, segmentation & reassemble) 


IrcOMM 


(RS232C emulation) 


Tiny TP 
IrLMP-IAS (flow-control for a multiplexed channel) 


(information Access Service) 


IrLMP-MUX (Link Management Protocol) 
IrLAP (Link Access Protocol) 
IrDA-SIR 1.0(-115.2kbps)/SIR 1.1 (-4.0Mbps) 


1.3. SCEP and bFTP 


SCEP establishes a session on ItCOMM and provides a transparent session which notifies an upper layer of 
a command. The procedure of SCEP is developed by a lower layer’s making use of an advantage that an 
IrDA protocol is “error free”, as a high speed session layer matching the IrDA protocol. 


As is apparent from its name, bFTP provides a service for transferring a binary file. The bFTP assumes a 
virtual file system together with a communication protocol. The bFTP has an aspect that it can be easily 
implemented, because it assumes such a simple file system that will allow “a binary file to be stored with its 
name”. 
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Moreover, bFTP is characterized by a query function which allows to query about functions and properties of 
a device and the image format available in the theme of this section, i.e., the image transfer. This query 
function simplifies the user interface of a digital camera, and allows the most suitable data of an image to be 
transferred between the digital cameras or printers faced with each other. In addition, this function makes it 
possible for the user to transfer, communicate or print suitable image data regardless of the difference in 
platform or model just by “selecting a photograph to be sent and pushing a transmission button”. 


1.4. Image Format UPF (Uni Picture Format) 


As mentioned earlier, UPF is the standard of an image format not included in the category of the IrDA 
standard. The IrDA standards are originally provided for defining and standardizing a protocol in 
connection with infrared communications. Accordingly, it is out of the scope to define the contents of an 
image transfer. However, in order to ensure mutual connectivity as an application of a digital camera, it is 
required to decide an image format so that image data sent via infrared communication is reliably 
reproduced. Therefore, in advocating IrTran-P as a standard to IrDA, the specific contents of an image 
format of IrTran-P are defined and described in an appendix. 


UPF is an image file format based on the JPEG base line. JFIF, which is a JPEG file, makes an image of 
various color forms available and employs a high level of compression scheme. For this reason, JFIF may 
be regarded as the industry standard of an image file format today. Since JPEG is a format enabling a 
variety of color forms, a compromise is required to some extent in order to realize the standard at a low cost, 
such as adopting only a part of the format as the standard. In UPF, among the formats included in the base 
line of JPEG, the format reliably allowing the devices at least to display and mutually transfer an image is 
defined as an indispensable one, and others are regarded as an option. For more details, please refer to the 
sections of UPF in the later part of this document. 


1.5. Study of Approach of UPF 


As well known, it is characteristic of a digital camera that all the data accompanying a photograph taken by 
a digital camera, such as a photo-taking date/time and the orientation (direction) of an image and other 
additional data, cannot be covered by the data within the JPEG format. In view of such a background, UPF 
is designed so that data is separated and stored on its own header arranged in the file without changing the 
image data scheme of JPEG Base Line at all. In addition, the header has expandability and allows a vendor- 
unique function to be added thereto. This makes it possible to separate the data necessary for a digital video 
camera from the data necessary for display and expansion of an image, which is advantageous in that the 
existing JPEG techniques can be used as it is. In a compact device like a digital camera, when using 
existing hardware or software, e.g. in the case where an algorithm of JPEG compression/expansion or the 
like is performed by hardware or is fixedly used as firmware, it is undesirable to change JPEG itself. 


As a further advanced step, UPF is designed so that additional data on an ambiguous point within the data of 
JPEG scheme is arranged in the header part. The additional data includes factors such as white level, black 
level and color-difference signal, necessary for reproducing an image with correct brightness and color. 


Though the format of a digital camera is being examined by various organizations, a conclusive decision 
has not been made yet. In many cases, there is proposed an arrangement such as newly addition of a tag to 
JPEG or the like. However, it will take a long time to reach the conclusion satisfactory for all the companies 
concerned, which is not a timely manner in view of the movements of the market today. The approach of 
making the best use of existing standard, wherein the data necessary for a digital camera is separated and 
added so as to assure expandability, is more realistic than the approach of waiting for the standard to be 
decided at last. 


IrTran-P (Infrared Transfer Picture) Version 1.0 October 1997 2 


Though UPF is defined as an appendix, it is indispensable for the IrTran-P standard to be able to support an 
image format of UPF scheme. 
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2. | Usage Model and Operations of IrTran-P 


This section describes how “operations” of a user are reflected onto “SCEP/bFTP”, or data transfer 
procedures of IrTran-P, when IrTran-P transfers picture data. 


In IrTran-P, an operation which transfers picture data from a digital camera is started by a sender. 


(1) Operation by User 
A user operates a digital camera of the sender to cause the digital camera to be in a transmission 
state, with the use of “selection of a specific picture” and a “transmission button”’. 


It is supposed that the device of a receiver is always in a receiving state or caused to be in a picture 
data receiving state by a “reception button”. 


(2) Establishment of Session by SCEP 
The digital camera of the sender carries out a discovery procedure by IrDA protocols and performs 
a connection for physical to ItCCOMM layers of IrDA protocols in accordance with IrDA protocols. 
When a transmission path of IrDA is established, SCEP makes a “session establishment request” 
from the sender toward a digital camera, printer or PC of the receiver. If the receiver is 
implemented with SCEP, it must make a response of either “session established” or “session 
establishment rejected”. 


(3) Query Operation by bFTP (Query function) 
When a session by SCEP is established, the digital camera of the sender issues a Query request in 
order to recognize picture processing functions of the receiver. The information mutually 
exchanged by the Query request includes the transmittable/receivable picture size, the picture 
compression format and the basic picture size of the device. Since this information is exchanged 
before transfer of picture data, the picture data can be transferred in “the most reasonable format” 
between devices of different platforms. 


In IrTran-P, a “mandatory format” is defined among the picture data formats of both sides, whereby 
a picture can be reliably exchanged between device of different grades or manufactures. 


Furthermore, it is possible to query about the power supply condition of the device, the receivable 
data capacity and the like. This makes it possible to deal with applications of a portable system. 


(4) Transfer of Picture Data by bFTP 
Transfer of picture data is started since the most appropriate picture format for both of the sender 
and the receiver is determined by Query.. SCEP performs the data transfer at a high transmission 
rate by making use of IrDA protocols. After the file transfer is completed, next picture data may be 
subsequently transmitted, or a session may be disconnected by SCEP. (Accordingly, even a simple 
model can transmit more than one pictures in succession.) 


(5) Completion of Session by SCEP 
When the picture transfer has been completed, the digital camera of the sender disconnects a 
session by SCEP. Thereafter, a disconnection request is issued for ICOMM and lower layers of 


IrDA protocols, and the picture transfer operation is completed. 


Next, three exemplary simple operations will be specifically described using services of SCEP/bFTP. 
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21. Usage model 1 Simple model 


Following chart is the simplest usage model. This model describes the case of picture sending machine 
transmits only 1 picture and doesn’t inquire the receivable picture format, rest of the memory nor the 
reminding battery life. 


Sender is possible to send the mandatory picture format only. 


Sender Receiver 
ex) CAMERA ex) Printer 


Select a picture to be sent 
or take a picture 


} Receiving operation 


Sending operation { 


1 


Connection establishment request 
ne 


Connection establishment confirmation 


Put a picture 


Confirmation for put operation 


Disconnection 
NS 


2.2. Usage model 2 The case of sending the non-mandatory size 


When the sender have some picture format possible to send and different from the mandatory format, it is 
possible to use the query service for obtaining the receivable picture format of the receiver and select the 
picture format for the actual picture send. 

Following chart is the usage model when the XGA size picture was transferred. In this case, the receiver 
can receive not only the mandatory format picture but also the XGA size format picture. Sender can send 
not only the mandatory format picture but also the XGA size format picture. Sender recognizes that the 
receiver can receive the XGA size picture from the information in the query command response, and sends 
the XGA picture. Though it is left to the picture sending machine which picture format to be sent, in the 
most of the case, the highest priority of the receivable picture format should be chosen. 
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Sender Receiver 
ex) CAMERA ex) CAMERA 


Select a picture to be sent 
or take a picture 


J Receiving operation 


Sending operation J 


| 


Connection establishment request 


Connection establishment confirmation 


Query acceptable size 


Acceptable size = XGA or VGA 


Put a XGA picture 
———— 


Confirmation for put operation 


Disconnection 
UE cool 


2.3. Usage Model 3 The case of sending the plural pictures 


Put command can be sent repetitively for sending more than one pictures. If the picture receiving machine 
can’t receive pictures over the certain number, then return the error code on the put response. 
The sender which has received an error response should terminate communication. 


Following chart is the usage model when the plural pictures were transferred. In this case, the receiver can 
receive up to 2 pictures, but sender tried to send 3 pictures. Since receiver can’t receive the 3™ picture, it 
skips to read the all of 3 picture data and return the error response. The sender resigned to send 3" picture 
and terminate communication. 


Sender Receiver 
ex) CAMERA ex) CAMERA 
Select 3 pictures to be sent 
1 Receiving operation 
Sending operation 1 
} Connection establishment request 
es 


Connection establishment confirmation 


Pee ee 


Put a Ist picture 


———_—_—_—_———— 


Confirmation for put operation 


Put a 2ndpicture 
SS 


Confirmation for put operation 


> ee ee 


Put a 3rd picture 
SS 


Error for put operation 


ee ee 


Disconnection 
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2.4. Closing Remark 


As apparent from above description, the picture data exchange by IrTran-P is though quite simple, yet 
powerful as well. Within the application range of a digital camera in the consumer market, this 
implementation is sufficiently effective by itself. As for bFTP, the definition is such that it can be expanded 


to support formats other than this simple one, and therefore will grow with functional development in the 
future. 
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3. Protocol (SCEP & bFTP) 


IrTran-P is to place a SCEP and a bFTP which are necessary for exchanging an image between devices and 
mutually recognizing properties of the devices, as the upper layer of IrSIR, LAP, IrLMP and IrCOMM. 


3.1. Introduction 


SCEP offers a connection management and command management service on a reliable stream-type 
transport layer. bFTP is a definition of a protocol for providing file transfer service for SCEP. 


3.1.1. Overview 


The connection management service of SCEP provides a user with a function of invoking the PDU(Protocol 
Data Unit) size receivable at a time and an authentication function using a password encoded by the user’s 
name and MDS(Message Digest 5). The command management service provides with a user functions of 
returning the result of command execution to the user, interrupting command execution, and segmenting or 
reassembling PDU so as to be receivable by the other side. 


The file transfer service is performed by a file transmission function and a file server function. The file 
transmission function is the sub-set of the file server function. This document defines the functions for 
realizing PUT model. Put Command to transmit a page of file is solely defined as the file transmission 
function. Query Command to inquire about processing abilities of an application on the responding side is 
solely defined as the file server function. 


S12. Terminology 


The following terms are used throughout this section. 
Primary — theentity that requests establishment of a SCEP connection. 


Secondary the entity that responds to the request for establishment of a SCEP 
connection. 


Requester the entity that transmits command request by using an established 
connection. 


Responder the entity that receives command request by using an established connection. 


3.1.3. Service Model 


SCEP and bFTP employs four generic types of service primitive: 


1. Request: Passed from the Upper Layer to invoke a service. 
Indication: Passed from <N> entity to the Upper Layer to indicate an event or to notify the Upper 
Layer of an <N> entity initiated action. 

3. Response: Passed from the Upper Layer to acknowledge some procedure invoked by an indication 
primitive. 

4. Confirm: Passed from <N> entity to the Upper Layer to convey the results of the previous service 
request. 
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<N> entity means SCEP or bFTP. <N> entity uses these primitives to communicate with the upper layer in 
order to manage the communications processes. 


These primitives are shown graphically here. 


Upper Layer Upper Layer 
SDU1 SDU2 Service Data Unit SDU2 SDU1 
Request Confirm Response Indication 
(xxx.req) v (xxx.cnf) (xxx.sp) ¥ (xxx.ind) 
DN Senie( > ——z—z—_—_—_—_E_E_E_£{_{—{_{_£{_—~—as~—_—__—_—_— 
<N> entity <N>entity 
A A 
<N> Header _[_SDU2 


<N> Header [| SDUI 


xxx PDU (Protocol data Unit) 


3.1.4. Bit and Byte Ordering 


This section regards frames as collections of bytes (octets) with each byte being composed of 8 bits numbered 
0-7. Bit 0 is always the least significant bit (LSB) and bit 7 is always the most significant bit (MSB). Bytes 
are represented throughout this section in the following forms: 


m Diagrammatic - a byte is represented by a rectangle. In some cases bit fields have special 
meaning and are indicated for clarity. The most significant bit is the bit on the left and the least 
significant bit is the bit on the right. An example is given below. 


FREER EPP 


m= Hexadecimal - a byte is represented with two hex digits with the least significant nibble on the 
right, the most significant nibble on the left, and both digits suffixed by “~h’. An example is the 
value 5 which is written as OSh. 


= Multiple bytes form - is represented as a rectangle with slots for each byte. The least significant 
byte is on the right and the most significant byte is on the left. The multiple bytes example shows 
a four bytes sequence of ~AQh’, ~BOh’, ~COh’, ~DOh’ : 


lbyte Ibyte lbyte Ibyte 
“AOh’ “BOh’ “COh’ | ‘Doh’ 


3.1.5. References 


[1] ISO7498, “Information processing systems - Open Systems Interconnection - Basic 
Reference Model’, 1984 


[2] Infrared Data Association, ‘IrCOMM)’: Serial and Parallel Port Emulation over IR (Wire 
Replacement)’, October 1995 
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[4] 


RFC1321, “The MDS Message-Digest Algorithm’, 1992 

IEEE EUI-64, “Extended Unique Identifier, 64bits)” 

ISO/IEC646, “Information Technology - 7-bit coded character se for information 
interchange”, 1991 

ISO8859-1, “Information Processing - 8-bit Single-byte coded graphic character sets - 
Part 1: Latin alphabet No. 1”, 1987 

ISO/IEC 10918-1, “Information technology- Digital compression and coding of 
continuous-tone still images: Requirements and guidelines (JPEG)’, 1994 
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3.2. SCEP (Simple Command Execute Protocol) 


This section defines SCEP, which execute communication job (command) and reports back the results 
between applications. 


3.2.1. Service Definition 


SCEP is intended to define a protocol to manage a connection and commands. 


3.2.1.1. Service Model 


The figure below shows a model of how SCEP fits into a typical system. This figure represents the SCEP 
reference model. 


User Application 
SCEP Services SCEP Services 
eS Command > < eS Connect 
eS_CommandID eS_ Disconnect 
eS_ Abort SCEP 
General Data Stream Services > —_—_——_ 
Open 
Close 
*Read Reliable Data Stream 
eWrite 


The elements for the SCEP reference model are described below. 
SCEP Services SCEP Service primitives which are provided to the SCEP user. 


SCEP Provides a connection management, command management and segmentation & 
reassemble mechanism. 


Command The element executed on server application. 


CommandID Identifier to manage the executing command. The executing commands have different 
CommandID. 


MachineID Identification number to tell one machine from another, and must be described in IEEE 
EUI64 format. In the case of a machine not requiring individual recognition, the 
machine does not need to have MachineID. As for the machine without MachineID, 00h is 
entered in the field of MachineID (eight octets). 

PID Identifier to distinguish the server process which is one of the application. 


General Transport Services Service which is provided by reliable data stream. 


Reliable Transport Layer Provide a reliable data stream mechanism. An example is the TCOMM 
defined by IrDA. 
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3.2.1.2. 


SCEP Service Primitives 


The SCEP interface provides the following services. 


= Connect 
= Disconnect 
= Command 


= CommandID 


= Abort 


3.2.1.2.1. 


S_Connect.req ( 


S_Connect.ind ( 


S_Connect.rsp ( 


S_Connect.cnf ( 


Connect services 


Primary MachinelD, 
Secondary MachinelD, 
Primary CFLG, 
Primary NegI nf 


Primary MachinelD, 
Secondary MachinelD, 
Primary CFLG, 
Primary NegI nf 


AckOrNackF lag, 
Primary MachinelD, 
Secondary MachinelD, 
Secondary CFLG, 
Secondary NegI nf 


AckOrNackF lag, 
Primary MachinelD, 
Secondary MachinelD, 
Secondary CFLG, 
Secondary NegI nf 


) 


The Connect services are used to establish a communication path with a peer SCEP system. This is a 
confirmed service. Upon receipt of an S_Connect.ind primitive the Secondary must either accept or reject the 
incoming connection. Connections are accepted by an invocation of S_Connect.rsp (Cack) or are rejected by 
an invocation of S_Connect.rsp (Cnack) or S_Disconnect.req with a reason of ‘User Disconnect’. 


Parameter used in this definition are as follow. 


PrimaryMachineID, SecondaryMachineID 
MachinelID of the side requesting Connection is referred to as Primary MachineID, and the MachineID 
of the side receiving Connection as Secondary MachineID. When Secondary MachineID is not 
specified, OOh is entered in the field of Secondary MachineID. 


CFLG 


A flag indicating whether or not being able to be Responder. If not being able to be Responder, neither 
Req PDU nor Rqs PDU is acceptable. 
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NegInf 
Negotiation information of SCEP connection which is value of a receivable maximum PDU size and 
authentication data including the user name and password.. 


AckOrNackFlag A flag indicating a permission or rejection to the connection request 
Ack Accepting a connection request 
Nack Refusing a connection request 


SCEP Services 
Primary Vv Vv Secondary 
S_Connect.req 


ere pee 


3.2.1.2.2. Disconnect services 


S_Connect.ind 


S_Connect.rsp 


S _Disconnect.req ( ReasonCode ) 
S_Disconnect.ind ( ReasonCode ) 


The Disconnect service is used to close the connection between SCEP entities. The Disconnect services are a 
non-confirmation type service. The user of SCEP is always permitted to use this service whenever it wishes 
to release the connection. The Disconnect service is used in these cases. 


m= =If a SCEP user wishes to release or abort a SCEP connection with a peer SCEP entity, it will use 
this service. 

m= If the underlying communication path is disconnected, SCEP will notify the SCEP user via an 
S_Disconnect.ind. 
A SCEP user uses Disconnect service to refuse an incoming connection. 
An S_Disconnect.ind is issued if the underlying layer failed to establish a connection. 


Parameter used in the Disconnect services are as follows. 


ReasonCode 
This parameter indicates the reason why a link is disconnected or why a connection is refused. 
“ReasonCode’ should be one of the following: 


Unspecified Reason 
The reason is unspecified in this document. 


User Disconnect 
The Responder refuse to establish a SCEP connection, or a SCEP user wishes to 
disconnect the existing connection. 


Provider Disconnect 


The provider of SCEP connection (SCEP or an underlying protocol stack) causes a 
disconnection. 
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SCEP Services 
Primary vV vV Secondary 
S_Disconnect.req 


S_Disconnect.ind 


‘User Disconnect’ or 
‘Unspecified Reason’ 


‘User Disconnect’ or 
‘Unspecified Reason’ 


SCEP Services 


Primary vV vV Secondary 
S_Disconnect.req 


S_Disconnect.ind , ; 
‘User Disconnect’ or 


i ‘ F : 
‘User Disconnect’ or Unspecified Reason 


‘Unspecified Reason’ 


SCEP Services 
Primary vV vV Secondary 


S_Disconnect.ind S_Disconnect.ind 


‘Provider Disconnect’ or 
‘Unspecified Reason’ 


‘Provider Disconnect’ or 
‘Unspecified Reason’ 


3.2.1.2.3. Command services 


S_Command.req ( Requester MachinelD, 
Responder MachinelD, 
Requester PID, 
Responder PID, 
UserData ) 
S_Command.ind ( Requester MachinelD, 
Responder MachinelD, 
Requester PID, 
Responder PID, 
CmdlD, 
UserData ) 
S_Command.rsp ( AckOrNackF lag, 
Requester MachinelD, 
Responder MachinelD, 
Requester PID, 
Responder PID, 
CmdlID, 
UserData ) 
S_Command.cnf ( AckOrNackF lag, 
Requester MachinelD, 
Responder MachinelD, 
Requester PID, 
Responder PID, 
CmdlD, 
UserData ) 
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The Command service is used to convey commands and results between SCEP users. The Command service 
is a confirmed service. 


The parameter used in this service is as follows. 


RequesterMachineID, ResponderMachineID 
ID for identifying a machine. MachineID used in S_Connect service must be used. MachineID of the 
side requesting Command is referred to as Requester MachineID, and the MachineID of the side 
receiving Command as Responder MachineID. 


RequesterPID, ResponderPID 
ID for identifying a SCEP user. RequesterPID is ID by which a user of S_Command.req can be 
identified. S_Command.cnf is given to the user specified at RequesterPID. ResponderPID must be the 
ID which allows identification of a server (SCEP user) which can execute a command requested by 
Requester. bFTP server’s PID = 8. 


UserData 
Data to be sent 


AckOrNackFlag 
indicates whether or not command execution is normally completed 
Ack indicates that command execution is normally completed 
Nack indicates that command execution is abnormally terminated 
3.2.1.2.4. CommandID services 
S_CommandlD.ind ( Requester PID, 
Responder PID, 
CmdlD ) 


The protocol machine of the Requester which has received S_Command.req must generate and manage IDs 
identifying S_Command.req (i.e., CmdID). In addition, after generating an ID, this ID must be returned to a 
user of S_Command.req through S_CommandID.ind service. When receiving a command interrupt request 
and a command response, a specified CmdID must be deleted from a management table. When 
disconnecting the connection, every CmdID should be deleted from the management table. The algorithm 
realizing these depends on implementation. 


The protocol machine of the Responder must preserve and manage the received CmdID. When receiving a 
command interrupt and a command response, a specified CmdID must be removed from a management table. 
When disconnecting the connection, every CmdID must be deleted from the management table. The 
algorithm realizing these depends on implementation. 

The parameter used in this service is as follows. 


RequesterPID, ResponderPID 
ID for identifying a SCEP user. RequesterPID is ID allowing identification of a user of 
S_Command.req. S_Command.ind is notified to a user specified at ResponderPID. ResponderPID 
must be ID allowing identification of a server (a SCEP user) which can execute a command requested 
by a Requester. 


CmdID 
ID for identifying a command. This is used when using S_Abort service. 
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SCEP Services 
Primary Vv vV Secondary 
S_Command.req 


ag S_Command.ind 
S_CommandID.ind >| 


S_Command.rsp 


IRequestet IRespond¢r 


S_Command.cnf 


ee 
SCEP Services 
Primary vV vV Secondary 
S_Command.req 
S_Command.ind 
ag S_CommandID.ind 
Respond¢r S_Command.rsp Requester 
S_Command.cnf 
>| 
3.2.1.2.5. Abort services 


S Abort.req ( Requester MachinelD, 
Responder MachinelD, 
Requester PID, 
Responder PID, 
CmdlD ) 

S_ Abort.ind ( Requester MachinelD, 
Responder MachinelD, 
Requester PID, 
Responder PID, 
CmdliD ) 


It offers a function of interrupting command execution. The Abort services are a non-confirmation type 
service. 
The parameter used in this service is as follows. 


RequesterMachineID, ResponderMachineID 
ID for identifying a machine. MachineID used in S_Connect service must be used. 


RequesterPID, ResponderPID 
ID for identifying a SCEP user. RequesterPID is the ID which allows identification of a user of 
S_Abort.req. ResponderPID must be ID which identifies a server (a SCEP user) which can execute a 
command requested by a user of S_Command service. 


CmdID 
ID for identifying the command of which execution must be interrupted 
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SCEP Services 
Vv Vv 


S_Abort.req 
IRequeste S_Abort.ind 
IRespondgr 


SCEP Services 
Vv Vv 


S_Abort.req 
r S_Abort.ind 


3.2.2. SCEP Protocol Data Units 


3.2.21. Definitions 
SCEP PDU is constructed by SCEP header, Command header and User data. 


3.2.2.1.1. SCEP Header Structure 
SCEP header is constructed by MsgType and InfElements. SCEP header structure is below: 


00h | MsgType] InfElement 
dy} dd (*) 


InfType] InfValue 
(1) (*) 


00h | Oth 
(1) (1) 


Olh |Length] Data 
q) gd) | © 


10h Length | Parameter1] Parameter2| 
(1) q) q) (1) 


20h Length |ReasonCodd 
(1) q) *) 


MsgType should be one of the following: 
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MsgT ype 


10h: Connection establishment request 

11h: Connection establishment confirmation 
20h: Data (Command) 

30h: Disconnection 

Others: reserved 


InfType should be one of the following: 


InfType 


OOh: Version of MsgT ype 

Used only when MsgType is a connection establishment request 
Olh: Negotiation Information 

Used only when MsgType is a connection establishment request or 
an acceptance of connection establishment request. 
03h: UserData 

Used only when a MsgType is data. 

Length2 can exist only when Length] is FFh. 
10h: Extend in the future 

Used only when MsgType is connection establishment request 
20h: Reason 

Used only when MsgType is disconnection 
Ohters: reserved 


(n): n bytes, *: variable length, []: optional 


The fields included in this document are described in the network byte order (Big-endian). 


InfType} InfValue 
() (*) 


(2) SCEP Header of a single PDU when sending a command or a alls 


as Length1 | Length2 ae DFLG| Length3} Command Header | User Data 
() [2] () (2) (28) (*) 


(3) SCEP Header of plural PDU when sending a command or a jesult 


eee Length1 | Length2 ae DFLG| Length3] SeqNo]RestNo] Command Header | User Data 
(1) () [2] (1) () (2) (4) (4) (28) (*) 


m The details of Data included in InfValue, when InfType is Negotiation Information and UserData. 


m InfVer: Version of InfType 


m= Length? must exist only when Lengthl=FFh. If Length! has a value other than FFh, the Length2 


field must not exist. 


= When InfType is UserData, PDU exceeding the maximum receivable size requested at the time of 
connection establishment must be segmented so as to be accommodated within the size, and 
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SCEP Header shown with (3) must be used. In the case of single PDU, SCEP Header shown with 


(2) must be used. 
m When Length3=00h,the Command Header field and the succeeding UserData field are not 


present. 


3.2.2.1.2. Command Structure 


Command is constructed Command structure is below: 


Command Header User Data 
(28) (*) 


m The data structure to request for command execution and the result of command execution will be 


described. 
m This structure is composed of Command Header and User Data. 


m User Data is given through S_Command service. 
= Information necessary for the command execution is stored on User Data. 


3.2.2.1.3. Command Header Structure 


Command header structure is below: 


58h |PduTyp¢Length4| DST MachineI SRC MachineID] DST PID | SRC PID] CmdID UserData 
d)) dd (4) (8) (8) (2) (2) (2) (*) 
ea eae ee aE Se ee 


Length4 


PduType b/b6 00:ReqPDU 

b7b6 01: Rpl PDU(ACK) 
When command execution is normally completed, 
Command Header + User Data stores results of the command 
execution. 

b7b6 10: Rpl PDU(Nack) 
When command execution is failed, 
Command Header + User Data stores causes of failure. 

b7b6 11: Abt PDU 
Command execution is interrupted. 

bO - b5: reserved 


@ DST MachineID: MachineID of the side receiving PDU including Command Header 
@ SRC MachineID: MachinelID of the side sending PDU including Command Header 
@ DST PID: Program ID of the side receiving User Data succeeding Command Header 
@ SRC PID: Program ID of the side sending User Data succeeding Command Header 
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® CmdID: Command ID. ID for identifying a command, needed to be generated and managed by a 
SCEP protocol machine. A user uses this ID to identify a command when using an S_Abort 
service. 


3.2.2.1.4. Parameters 


CFLG The below combinations are available. 


CFLG = 00h: the machine can issue a command but cannot execute a command. 
CFLG = 04h: the machine can issue and execute a command. 
Others: reserved. 


DFLG Permitted Combinations and their meanings 


DFLG = Clh: When PDU is not segmented (Single PDU) 
DFLG = 41h: The first segmented PDU 

DFLG = Olh: Intermediate segmented PDUs 

DFLG = 81h: The last segmented PDU 

DFLG = C2h: Communication Interruption 

DFLG = C3h: Reject to request connection 

Others: reserved. 


3.2.2.1.5. Segmentation and Reassembling 


If the sending PDU size is greater than the receivable maximum PDU size which is negotiated at connection 
establishment, the sending PDU must be segmented not greater than the receivable maximum PDU size. 
Con PDU, Cnack PDU, Cnack PUD, Dis PDU, Abt PDU, Stp PDU must not be segmented. 


Command Header User Data 
(28) (*) 


SCEP Header SCEP Header SCEP Header SCEP Header 
(DFLG = 41 h) (DFLG = 01 h) +++ | (DFLG=01 h) (DFLG = 81 h) 


Reg PDU or Int PDU Int PDU Trm PDU 
Rpl PDU 


= Command Header + User Data is segmented into plural PDU s to be sent out. DFLG is used for 
identifying the first, intermediate and last PDU. 

m= Only when MsgType included in SCEP Header is 20h, it can be segmented. Otherwise, it must 
not be segmented. (Only the length equal to or less than the maximum receivable size is 
permitted.) 
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3.2.2.2. Con PDU 


SCEP protocol machine writes Con PDU packet to the data stream by an invocation of S_Connect.req. Con 


PDU packet structure is below: 
MsgType |InfType| InfType InfVer| 
00h 10h OOh |Olh] Olh |Length] 10h |CFLG]|Secondary MachineID] Primary MachineID] NegInf 02h ]00h }O0h 
My, @ gd) {@}] @ gd) | @ | @ (8) (8) *) G) {@ |{@ 
ge | 


Length 


InfType 
10h 
qd) 


The maximum length of Con PDU is 256bytes. Accordingly, the maximum length of 
NegI nf is 228 bytes ( =256 - 28). 


¢ Secondary Machine! D, Primary MachinelD 

e If unused, 0000 0000 0000 0000h is set. 

e¢ In the machine CFLG = 00h, the upper layer which has received S Connect.ind by 
ConPDU from the machine CF LG=00h should send S_Connect.rsp(N ack). 


Negi nf to convey a negotiation value of a frame size, authentication data and the 
like. The structure of NegI nf is below. 


NegVer 
11h 
() 


NegContent 
(*) 


NegVer 11h (fixed, indicating the version of NegInf). If the format of Neginf is 
different, other numerals must be used. When a different value is set, the entry to the 
second and succeeding bytes is ignored, and it is assumed that Negl nf is not specified. 
(It must not be regarded as an error). 


NegC ontent Text data conforming to the following BNF can be included. 
<is-list> := — { <tag>‘:’[<spc>][<value>]<crlf>}* 
<tag> := (Attribute Name, alphabet character 2 bytes. Case sensitive.) 
<spc> := (blank letter. One or more blank letters or the like between Attribute Value and a 


colon is ignored.) 


<value> := (Attribute value, regarded as 8 bits character string. A value 1Fh or less is not 
permitted. A value 8Fh or more is not permitted.) 

<crlf> := <CR><LF> 

<CR> := ODh 

<LF> := OAh 


The data not conforming to this BNF must not be included. If there are data against the BNF, it 
can be assumed that NegInf parameter is not specified. All items are optional. The four attributes 
are already defined. The unknown attributes which are not defined below can be skipped without 
reading. 


fr: n <CR><LF> 


For negotiation of PDU size: The sender invokes the maximum receivable size of a PDU and 
the receiver decides transmission PDU size in accordance with the invoked size. If this 
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Attribute is omitted, 512bytes becomes the maximum receivable PDU size. The maximum 
acceptable PDU size of sender may be different from that of the receiver. The following sizes 
are defined. 
n= ~1’:512bytes (default), ~2’: 1024bytes, 
~3°: 2048bytes, ~4’: 4096bytes 


id: (Products Identification Character String)<CR><LF> 
Products Identification Character String: The character string specified by the products 
vendor. It is recommended that the type of machine (model number, type code e.g.) is 
suffixed to the character string of the company name. 


nm: (User Name)<CR><LF> 
User Name: It is possible to specify any bytes string except <CR><LF>. 32 bytes at 
maximum. 


pw: (Password)<CR><LF> 
Password: The hexadecimal expression of a fingerprint (16bytes) fetched by encoding the 
password character string (ASCII code) entered by a user by MD5. In the hexadecimal 
expression, a space must not be inserted between characters. (For example, the form of “FE 
80 FE 80” is not permitted. It should be the form of ~FE80FE80’) 


If the same Attribute name appears at plural times, the Attribute value appearing later becomes 
effective. 


The NegInf are limited to a total encoded size of 228 bytes. 


3.2.2.3. Cack PDU 


SCEP protocol machine writes Cack PDU packet to the data stream by an invocation of S_Connect.rsp 
which connection is accepted at the Secondary. Con PDU packet structure is below: 


oon [set ypetintlypely noth [Ye] CRLG| Primary MachineID |Secondary MachineID| NegInf 
ith | Oth 10h 
Ol ay Mall Osh ay | (8) (8) *) 
pg 


Length 


= Connection Establishment Certification PDU 
# NegInf are similar to Con PDU. 


3.2.2.4. Cnack PDU 


SCEP protocol machine writes Cack PDU packet to the data stream by an invocation of S_Connect.rsp 
which connection is rejected at the Secondary. Cnack PDU packet structure is below: 
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2 oon] MseType | InfType | Length! |InfVer] DFLG | Length3 
20h 03h 04h 10h | C3h | 0000h 
dd) (1) qd) | qd (2) 
rs 
Length1 
(2) 


00h MsgType | Inffype | Lengthl | Length2 |InfVer}] DFLG | Length3 
(1) 20h 03h FFh 0004h 10h | C3h | 0000h 
qd) qd) (2) gd) | (2) 


le 
Length2 


= SCEP Connection refusal PDU 
Format is (1) or (2). 


J2.2658 Dis PDU 


SCEP protocol machine writes Dis PDU packet to the data stream by an invocation of S_Disconnect.req. Dis 


PDU packet structure is below: 
00h Miss Type [ntl ype Length } ReasonCode 
(1) 30h 20h (1) (*) 
dd) dd) 
Dose = ae 


Length 


= SCEP Connection Disconnect PDU 
m ReasonCode 
0000h: Unspecified Reason 
0001h: User Disconnect 
0002h: Provider Disconnect 
Others: Reserved 


3.2.2.6.  Rqs PDU 


SCEP protocol machine writes Rqs PDU packet to the data stream by an invocation of S_Command.req 
which the PDU size is not greater than the receivable maximum PDU size of the Responder. Rqs PDU 
packet structure is below: 


00h MsgType} InfType Length] | Length2 inven DELS Length3,| Command Header }_ User Data 
(1) 20h 03h (1) [2] 10h J[Clh (2) (28) (*) 
(1) (1) gd) | 
a ee 


Length1(Length2 field is omitted) 
or if Lengthl=FFh then Length2 
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= Command Request PDU (Single PDU) 
DFLG = Clh 
PduType in Command Header = 00h 
= Lengthl, Length2 
If Length! has a value FFh, next two bytes (Length2) indicate the length. 
= Length3 
To indicate the length of Command Header + User Data 
m If the whole length exceeds the maximum receivable PDU size, it must be segmented into plural 
parts to be Req PDU, Int PDU and Trm PDU, respectively. 


32261 Rps PDU 


SCEP protocol machine writes Rps PDU packet to the data stream by an invocation of S_Command.rsp 
which the PDU size is not greater than the receivable maximum PDU size of the Requester. Rqs PDU 
packet structure is below: 


SCEP Header 
OOh| Mse Type) Intl ype Length 1] Length Per Length4 Command Header! User Data 
(1) 20h 03h (dd) [2] 10h |Clh (2) (28) (*) 
(1) (1) qd) | @ ! 
ee 
Length1(Length?2 field is omitted) or 
if Length1=FFh then Length2 


m Result of the Command Execution PDU (Single PDU) 
DFLG = Clh 
PduType = 40h(Ack) or 80h(Nack) in Command Header 
= Lengthl, Length2 
If Length! has a value FFh, next two bytes (Length2) indicate the length. 
= Length3 
To indicate the length of Command Header + User Data 
m If the whole length exceeds the maximum receivable PDU size, it must be segmented into plural 
parts to be Rpl PDU, Int PDU and Trm PDU, respectively. 


3.2.2.8. Req PDU 


SCEP protocol machine writes Req PDU packet to the data stream by an invocation of S_Command.req 
which the PDU size is greater than the receivable maximum PDU size of the Responder. When the sending 
PDU is greater than the receivable maximum PDU size of the Responder, the sending PDU is segmented to 
Req PDU, Int PDUs and Trm PDU. Req PDU packet structure is below: 
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MsgType 
20h 
Q) 


OOh| 
(1) 


Hes a InfVer Segmented 
eee ata 10h | ath ee 00003000 ata ear Header! “User Data 
rN dd) |G) (4) a 


Length1(Length2 field is omitted) or if Lengthl=FFh then Length2 


= Command Request PDU (The first PDU when User Data is segmented into plural PDUs) 
DFLG = 41h 
PduType = 00h in Command Header 


= Lengthl, Length2 
If Length! has a value FFh, next two bytes (Length2) indicate the length. 


= Length3 
To indicate the length of Command Header + Segmented User Data. 


m SeqNo: The sequence number of this PDU. 0 is specified at the first PDU. 
m RestNo: The remaining number of segmented PDUs. | is specified at the last PDU. 


3.2.2.9.  Rpl PDU 


SCEP protocol machine writes Rpl PDU packet to the data stream by an invocation of S_Command.rsp 
which the PDU size is greater than the receivable maximum PDU size of the Requester. When the sending 
PDU is greater than the receivable maximum PDU size of the Requester, the sending PDU is segmented to 
Rpl PDU, Int PDUs and Trm PDU. Rpl PDU packet structure is below: 


ieee Hee He oo a DFLG],...,] seqNo |, .. 7... . Segmented 
a or a ae Ath [Beng th3 Roe ar soa aaa User Data 
ie) ray ay ie) 4) ) 


Length3 


Length1(Length?2 field is omitted) or if Lengthl=FFh then Length2 


= Command Execution Result Return PDU (The first PDU when User Data is segmented into plural 
PDUs) 
DFLG = 41h 
PduType = 40h(Ack) or 80h(Nack) in Command Header 
= Lengthl, Length2 
If Length1 has a value FFh, next two bytes indicate the length (Length2). 
m= Length3 
To indicate the length of Command Header + Segmented User Data. 
m= SeqNo: The sequence number of the PDU. 0 is specified at the first PDU. 
m= RestNo: The remaining number of segmented PDUs. | is specified at the last PDU. 


3.2.2.10. Int PDU 


SCEP protocol machine writes Int PDU packet to the data stream by an invocation of PDUConf which is 
internal event of the segmentation mechanism. When the sending PDU is greater than the receivable 
maximum PDU size of the Responder, the sending PDU is segmented to Req PDU, Int PDUs and Trm PDU 
by an invocation of S_Command.req. When the sending PDU is greater than the receivable maximum PDU 
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size of the Requester, the sending PDU is segmented to Rpl PDU, Int PDUs and Trm PDU by an invocation 
of S_Command.rsp. 


The segmentation mechanism invokes PDUConf event after sending out Req PDU or Int PDU until sending 
out the last PDU which is Trm PDU by an invocation of S_Command.req. The segmentation mechanism 
invokes PDUConf event after sending out Rsp PDU or Int PDU until sending out the last PDU which is Trm 
PDU by an invocation of S_Command.rsp. Int PDU packet structure is below: 


oon} MseType| InfType |r nothi| Length2|VerPFLG] | enoth3| SeqNo| RestNo Beeinentee 
ay 208 03h oO 2} | 20h | otn Pc, a | @ User Data 
(1) (1) dd) | dd) (*) 


Length3 


Length1(Length?2 field is omitted) or 
if Lengthl=FFh then Length2 


m Intermediate PDUs of command request or result of the command execution 
(Intermediate PDUs when User Data is segmented into plural PDUs ) 

DFLG = 01h 

= Lengthl, Length2 
If Length! has a value FFh, next two bytes (Length2) indicate the length. 

= Length3 
To indicate the length of User Data 

m SeqNo: The sequence number of the PDU. 0 is specified at the first PDU. 

m RestNo: The remaining number of segmented PDUs. | is specified at the last PDU. 


3.2.2.11. Trm PDU 


SCEP protocol machine writes Trm PDU packet to the data stream by an invocation of PDUConf which is 
internal event of the segmentation mechanism. When the sending PDU is greater than the receivable 
maximum PDU size of the Responder, the sending PDU is segmented to Req PDU, Int PDUs and Trm PDU 
by an invocation of S_Command.req. When the sending PDU is greater than the receivable maximum PDU 
size of the Requester, the sending PDU is segmented to Rp! PDU, Int PDUs and Trm PDU by an invocation 
of S_Command.rsp. 


The segmentation mechanism invokes PDUConf event after sending out Req PDU or Int PDU until sending 
out the last PDU which is Trm PDU by an invocation of S_Command.req. The segmentation mechanism 
invokes PDUConf event after sending out Rsp PDU or Int PDU until sending out the last PDU which is Trm 
PDU by an invocation of S_Command.rsp. Trm PDU packet structure is below: 


MsgType] InfType InfVer]DFL RestNo Segmented 
03h a oe 10h | 81h a at 00000001h User Data 
(1) (1) (1) | dd) (4) C) 
Pte 


Length1(Length2 field is omitted) or 
if Lengthl=FFh then Length2 
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m The last PDU of Command Issue or Command Execution Result (The last PDU when User Data 
is segmented into plural PDUs) 
DFLG = 81h 
= Lengthl, Length2 
When Length! has a value FFh, next two bytes (Length2) indicate the length. 
= Length3 
To indicate the length of Segmented User Data 
m SeqNo: The sequence number of the PDU. 0 is specified at the first PDU. 
m RestNo: The remaining number of segmented PDUs. | is specified at the last PDU. 


3.2.2.12. Abt PDU 


SCEP protocol machine writes Abt PDU packet to the data stream by an invocation of S_Abort.req. Abt 
PDU packet structure is below: 


(1) InfType | Length! |InfVer|DFLG} Length3 
03h | 20h | 10h | Cth | 001Ch niki’ sania 
(1) (1) (1) | () (2) ! 
Length] 
(2) InfType | Length1 | Length2 |InfVer]| DFLG 
03h | FFh 10h | Cth | 001Ch aad aia 
(1) (1) (1) | dd) 


Length2 


= Command execution abort PDU 
The format is (1) or (2). 
DFLG = Clh 
PduType = COh 

= To interrupt the execution of SCEP command specified at DST PID and CmdID in Command 
Header. 
PDU when Abort.req is used after all the PDUs concerned with command request have been sent 
out. 


3.2.2.13. Stp PDU 
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3.2.3. 


(1) 00h MsgType | InfType | Length! |InfVer}DFLG | Length3 
(1) 20h 03h 04h 10h | C2h | 0000h 
d) d) d) Gd) | @® (2) 
ga = = I 
Length1 
(2) 00h MsgType | Inffype | Length! | Length2 |InfVer]DFLG | Length3 
(1) 20h 03h FFh 0004h | 10h | C2h | 0000h 
d) d) d) (2) Gd) | @ (2) 
( 
Length2 


= Transmission interrupt PDU of command execution or result of the command execution. 
Format is (1) or (2). 
DFLG = C2h 

= During transmission of PDU concerned with SCEP command execution, it is sent out to inform 
the transmission interruption. 

= When Abt PDU is sent out and the Responder tries to interrupt the SCEP command execution 
specified at DST PID and CmdID, if a part of PDU concerned with the execution result has been 
already sent out, it is sent out to interrupt this result and to inform the side started receiving the 
result that the receiving be interrupted. 


State Definition and Transitions 


This section contains a state transition table based on the SCEP service primitives described above. 
Descriptions of the states, events and actions are included. 


3.2.3.1. State Transition Table 


The state transition table of SCEP is given below. Initial state is CLOSED. When the action is not described, 
the input event is ignored and the state dose not transit. 
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State Transition Table of Connection Management 


[ [CLOSED WECC WECR OPEN 


SCONreq [CON 
WFCC 


-_ Pf 


SDISreq a DIS DIS 
CLOSED CLOSED _|CLOSED 


CACK : i 
DIS 
CLOSED; 
not p4:SCONcnf(ACK) 
OPEN; 


CNACK SCONcnf(NACK) 
CLOSED 


p3:CNACK SDISind 
CLOSED; CLOSED 
not p3:SCONind 
WFCR; 


CLOSED SDISind SDISind SDISind 
CLOSED CLOSED _|CLOSED 
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State Transition Table of Command Execution 


PDUconf 

SREQ; 
notP1:RQS 

SIDind 


TREO 


STP 
OPEN 


DIS 
CLOSED 


IP6:RPS(Nack) 
IREQ; 


P3:RPL 
PDUconf 
SRSP; 

notP3:RPS 
OPEN; 


SDISind 
DIS 
CLOSED 


SDISind 
DIS 
CLOSED 


SDISind 
DIS 
CLOSED 


SDISind 
DIS 
CLOSED 


SDISind 
DIS 
CLOSED 


SDISind 
DIS 
CLOSED 


SDISind 
DIS 
CLOSED 
SDISind 
DIS 
CLOSED 
STP 
OPEN 


RRSP. 


SCOMenf(Ack) 
OPEN 


SDISind 
DIS 
CLOSED 


OPEN 


ISCOMind 


SDISind 
DIS 
CLOSED 
SDISind 
DIS 
CLOSED 
SDISind 
DIS 
CLOSED 


SDISind 
DIS 
CLOSED 
SDISind 
DIS 
CLOSED 
SDISind 
DIS 
CLOSED 


TREO 


SDISind 
DIS 
CLOSED 


SDISind 
DIS 
CLOSED 


P5:SDISind 
DIS 
CLOSED; 
P6:SCOMcnf(Nack) 
STP 
OPEN; 


SDISind 
DIS 
CLOSED 


SDISind 
DIS 
CLOSED 


SABTind 
OPEN 


SDISind 
DIS 
CLOSED 


SDISind 
DIS 
CLOSED 


SDISind 
DIS 
CLOSED 


323.2. 


P2:INT 
PDUcenf 
SREQ; 

notP2:TRM 
WRSP; 


State Definitions 


The state definition for SCEP is given below. 


States of Connection Management 
CLOSED {Disconnection 
Wait for CackPDU Reception 


Wait for S_Connect.rsp 


SCEP Connection Already Set 
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PDUconf 

SRSP; 
notP4:TRM 

OPEN; 
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The State of Command Execution 
Sending Request 
Waiting for Reply 
Reply being Received 
Ignoring Reply: Command Execution Interrupted by S_Abort.req 
Reply being Received, but Reply being Received is Discarded 


Disconnection 

Request being Received 
Command being Executed 
Reply being Transmitted 
Ignoring Request 


3.2.3.3: Event Descriptions 


The input and output event for SCEP are given below. 


Input Event of Connection Management 


Input Event 


Internal Event Occurring When transmission of Req, Rsp, Int or Trm PDU is completed 
S_Command.req 

S_Command.rsp 

S_Abort.req 


3.2.3.4. Action Descriptions 
The action description for SCEP is given below. 
Predicates of Connection Management 


Connection Establishment Response 
Connection Establishment Rejection 


Not acceptable CON PDU 
Not Acceptable CACK PDU 
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Output Event of Connection Management 
SCONind }S_Connect.ind 

SCONcnf |S_Connect.cnf 

SDISind ]S_Disconnect.ind 
SCOMind]S_Command.ind 


Sum of SCEP Header, Command Header and SDU Exceeds Maximum Receivable PDU Size of Receiving Side 
Length of Remaining PDU Exceeds Maximum Receivable Size of Receiving Side 

Sum of SCEP Header, Command Header and SDU Exceeds Maximum Receivable PDU Size of Transmission Side 
Length of Remaining PDU Exceeds Maximum Receivable Size of Transmission Side 


Internal Event Occurring When transmission of Req, Rsp, Int or Trm PDU is completed 
S_Command.cnf 

S_Command.ind 

S_Disconnect.ind 

S_CommandID.ind 

S_Abort.ind 
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3.3. bFTP (binary File Transfer Protocol) 


3.3.1. Service Definition 


bFTP is intended to define a protocol that can be used to transfer files from peer to peer. This document 
describes the Query service and Put service. 


3.3.1.1. Service Model 


The figure below shows a model of how bFTP fits into a typical system, i.e., the bFTP reference model. 


bFTP Services 
¢F_Query 
°F Put 


SCEP Services 


°¢S_Command 
°¢S_CommandID 
°S_ Abort 


User Application 


: SCEP Services 
> v < ¢S_Connect 


°S_Disconnect 


The elements for the bFTP reference model are described below. 


bFTP Services 


bFTP 


SCEP Services 


SCEP 


bFTP Service primitives which are provided by bF TP. 
protocol providing a file transfer and virtual file server mechanism. 
SCEP Service primitives which are provided by SCEP. 


protocol providing a connection management, command management 
and segmentation & reassemble mechanism. 


3.3.1.2. bFTP Service Primitives 


3.3.1.2.1. Query Service 


F_Query.req ( 


Responder MachinelD, 
Requester MachinelD, 
Requester PID, 
What ) 
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F_ Query.ind ( Responder MachinelD, 
Requester MachinelD, 
Requester PID, 
What ) 

F_ Query.rsp ( AckOrNackF lag, 
Responder MachinelD, 
Requester MachinelD, 
Requester PID , 
Result ) 

F_ Query.cnf ( AckOrNackF lag, 
Responder MachinelD, 
Requester MachinelD, 
Requester PID , 
Result ) 


Query service is used to obtain the processing ability of the application on the responder. This is confirmed 
service. F_Query service is provided by using S_Command services of SCEP. Responder MachineID, 
Requester MachineID, Requester PID and AckOrNackFlag respectively correspond to the parameters of 
S_Command services. Responder PID which is one of the parameter of S_Command services should be 8. 


Requester PID 
identifies the bFTP-user that has issued F_Query.req. 


What 
indicates what category of processing abilities of the Responder. The value of ‘What’ should be one of 


the following: 


RIMG to inquire information of a still-image which can be processed by the Responder. 
RINF _ to inquire a status of the Responder. 
RCMD to inquire commands which can be executed by the Responder. 


AckOrNackFlag 
indicates the status whether the command execution is success or failure. The value of the flag is Ack 
or Nack respectively. 


Result 
indicates the results of the command execution. If AckOrNackFlag = Ack, it indicates the processing 
ability of the responder which is specified at ‘What’. If AckOrNackFlag = Nack, it indicates an error 
code. 


bFTP Services 
Vv 


F_Query.req 


F_Query.ind > 


IRequester IResponder 
F_Query.rsp 


F_Query.cnf 


<e 
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3.3.1.2.2. Put services 


F_Put.req ( Responder MachinelD, 
Requester MachinelD, 
Requester PID, 
FileName, 
UserF ileN ame, 
Time, FileHeader, 
Thumbnail, 
File ) 
F_Put.ind ( Responder MachinelD, 
Requester MachinelD, 
Requester PID, 
FileName, 
UserFileN ame, 
Time, 
FileHeader, 
Thumbnail, 
File ) 
F_Put.rsp ( AckOrNackF lag, 
Responder MachinelD, 
Requester MachinelD, 
Requester PID , 
Result ) 
F_Put.cnf ( AckOrNackF lag, 
Responder MachinelD, 
Requester MachinelD, 
Requester PID , 
Result ) 


Put service is used for sending a named file to the Responder. The Put services are a confirmed-service. 
F_Put service is provided by using the S_Command services of SCEP. Responder MachineID, Requester 
MachineID, Requester PID and AckOrNackFlag respectively correspond to the parameters of S_Command 
services. Responder PID which is one of the parameter of S_Command services should be 8. 


Requester PID 
indicates ID number to identify the bFTP-user which has issued F_Query.req. 

FileName 
indicates the name of the file. The file name must be a character string of ASCII 8.3 format. The 
maximum length is 31 bytes. 

UserFileName 
indicates the long file name of the file. The file name must be a character string in the format of 
SJIS(Shifted-JIS Code), ASCII or ISO8859-1. 

Time 
indicates the time at which the file is created or modified. This must be a character string expressed in 
the *YYYYMMDDHHMMSS’ (year, month, day, hour, minute, second) format. 

FileHeader 
indicates the information of File or Thumbnail. This is not used in this document. 
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Thumbnail 
indicates the scale-down image when the contents of the file is a still-image. This is not used in this 
document. 
File 
indicates a file itself to be transferred. 
AckOrNackFlag 
indicates in what state the command execution is finished. 
Ack indicates that the command execution is successfully completed. 
Nack indicates that the command execution is abnormally terminated. 
Result 
indicates the results of the command execution. If AckOrNackFlag = Ack, it indicates the name of File 
given when File is stored by the Responder. The file name must be a character string of ASCII 8.3 
format. The maximum length is 31 bytes. If AckOrNackFlag = Nack, it indicates an error code. 


bFTP Services 
Vv Vv 


F_Put.req 


F_Put.ind 


IRequester IResponder 
F_Put.rsp 


F_Put.cnf 


<e 


3.3.2. bFTP Protocol Data Units 


3.3.2.1. Attribute Structure 


bFTP protocol data units are carried as the user data of SCEP PDU. The bFTP protocol data unit has a 
structure as shown below. 


AttName 
(4) 


AttLength 
(n): n bytes, *: variable length, []: optional 


The bFTP protocol data unit is composed of AttNum field and some Attribute fields. AttNum specifies the 
number of Attribute fields which are included the PDU. An Attribute field includes AttName field, 
AttLength field, AttType field, AFLG field and AttValue field. 


AttNum The number of Attribute fields. 
AttName Attribute field Name 
AttLength The Length of Attribute 
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AttName field represents characteristics of each Attribute field. AttName should be one of the following: 


AttType Attribute Type 
00h Binary Type 
Olh Character Type, SJ 1S, 1S08859-1 or ASCII 
06h Time Type, a character string of YYYYMMDDHHMMSS' 
format 
Others reserved 

AFLG Supplementary Data 
00h No Supplementary Data 
Others reserved 

AttValue Attribute Real Data 

Attributes 


m File Name 
AttName 
AttType 
AttValue 


= User File Name 


AttName 
AttT ype 
AttValue 


= Time 
AttName 
AttType 
AttValue 


m File Header 
AttName 
AttT ype 
AttValue 


a Thumbnail 
AttName 
AttType 
AttValue 


= Body 
AttName 
AttT ype 
AttValue 


“FILO” 

Character Type 

File name. It must be written in a character string of 
ASCII 8.3 format. 


“LFLO” 

Character Type 

The long file name of the file. It must be written in 
a character string of SJIS or ISO8859-1. 


“TIMO” 

Time Type 

The time at which the file is created or modified. 
It must be written in a character string of 
“YYYYMMDDHHMMSS’ format. 


“TYPO” 
Binary Type 
The information of the File or Thumbnail. 


“TMBO” 
Binary Type 
The scale-down image. 


“BDYO” 
Binary Type or Character Type 
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= Command 


AttName “CMDO” 
AttType Binary Type 
AttValue Command Name 


= Category to be Queried 


AttName “WHTO0” 
AttType Character Type 
AttValue Category Name 
m Error 
AttName “ERRO” 
AttType Binary Type 
AttValue ERRCODE 
m Result 
AttName “RPLO” 
AttType Character Type 
AttValue Stored File Name 


3.3.2.3. File Information 


The file information is expressed as the list of Attributes where attribute data and contents of File are joined 
together. The Attributes must appear in the order as shown in the below table, but Attributes with 


‘(optional)’ can be omitted. 
‘AttType J AFLG 
Olh 00h AlN allie eUserFileName (optional) 
(4) (1) (1) (*) 


Attlype JA 
Attlength 06h 00h AttValue 


(ye say = 
Pee ae AttValue FileHeader (optional) 


a ja] © 


‘AttType | AFLG Thumbnail : 1 
AttValue umbnail (optional) 

00h 00h (*) 
() () 

AttType | AFLG *Bod d 

AttValue ody (mandatory) 

00h 00h (*) 
() () 


eTime (optional) 


Attlength 


3.3.2.4. Query_Req PDU 


Query_Req PDU is configured by setting the parameter What of F_Query.req primitive to AttValue of 
AttName=WHT0”. Query_Req PDU is UserData of S_Command.req and S_Command.ind. 
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AttNum 
0002h 
(2) 


AttName] Attlength | AttType}] AFLG | AttValue 
“CMDO” |00000006h} 00h 00h |00010040h| 
AttName] Attlength | AttType}] AFLG | AttValue 
“WHTO” |00000006h} Olh 00h 


AttValue of AttName=’WHT0” 


“RIMG” 


“RINE” 


“RCMD” 


3.3.2.9: Query_Rpl PDU 


eThe number of Attributes (mandatory) 


eCommand (mandatory) 


*Category to be Queried (mandatory) 


indicates what category of the processing ability 
of the responder is desired to query 
about. ‘Attribute’ should be one of the following. 


is used when it is desired to know the data on a 
still image which can be processed by the 
responder. 


is used when it is desired to know the data on 
the responder system which is related to the 
responder. 


is used when it is desired to know the data on 
the commands which can be processed by the 
responder. 


When the command execution is successfully completed, i.e., at the time of the parameter AckOrNackFlag 
of F_Query.rps primitive = Ack, Query_Rpl PDU is configured by setting the parameter Result of 
F_Query.rsp primitive to AttValue of AttName=”BDY0”. Query_Rpl PDU is UserData of S_Command.rsp 


and S_Command.cnf. 


AttNum 
0001h 
(2) 
AttName AttType} AFLG 
“BDY0” Attlength 00h 00h eps *Query Result Data (mandatory) 
(4) (1) (1) 
AttValue indicates the processing ability of the responder which is specified at 


Query Reg. This should follow the below-listed BNF representation. 


Representation of Symbols 
<> variable 


option 

repeatable zero or more times 
repeatable one or more times 
definition 


i+ *o 
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(...) explanation 


At the time of WHT0 = ''RIMG" 

AttValue=  <rimg> 

<rimg> := <tag-pix-aspect><pix-aspect>] 
tag-org-size><original-size>] 
tag-acc-size><num-acc-size> { <accept-size> }+] 
<tag-org-samp><original-sampling>] 
<tag-acc-samp><num-acc-samp> { <accept-sampling> }+] 
<tag-acc-filesize><accept-filesize>] { <tag-option><option> }* 


< 
< 


[ 
[ 
[ 
[ 
[ 
[ 


<tag-pix-aspect> := 00h 

<pix-aspect> := units in width (1byte) x units in height (1byte) 
indicates the aspect ratio of pixels. The default value of 0101h stands for the pixels at the ratio of 1 : 
1. With FFFFh, the aspect ratio is ignored. 


<tag-org-size> := Olh 
<original-size> := <QVGA> | <VGA> | <SVGA> | <XGA> | <SXGA> | <FREE> 
indicates the original lattice size of the Responder. 
If the Requester can transmit an image suitable for this field, the image can be transmitted without 
conversion. 
If <accept-size> field is present, there is no default. If not, the default is <VGA>. 


<tag-acc-size> := 02h 

<num-acc-size> := (the number of <accept-size>, hexadecimal, | byte) 

<accept-size> := <QVGA> | <VGA> | <SVGA> | <XGA> | <SXGA> | <FREE> 
The transmission side has to send an image of the size of the lattice included in this field. The 
default is <VGA>. 


<tag-org-samp> := 03h 
<original-sampling> := <compressed-420> 
indicates the sampling method of the Responder. If the Responder can transmit an image suitable for 
this field, the image can be transmitted without conversion. 
If <accept-sampling> field is present, there is no default. 
If not, the default is <compressed-420>. 


<tag-acc-samp> := 04h 

<num-acc-samp> := (the number of <accept-sampling>, hexadecimal, | byte) 

<accept-sampling> := <compressed-420> 
The transmission side has to send the image of sampling included in the <accept-sampling> field. 
The default is <compressed-420>. 


<tag-acc-filesize> := 05h 

<accept-filesize> := (the maximum receivable size, the bytes number divided by 256 is entered, 4bytes) 
The transmission side must send the image of a size equal to or smaller than the size included in the 
<accept-filesize> field. 
The receiving size has to assure receiving of images of this size. 
The default is 00000200h(128Kbytes). FFFFFFFFh indicates that any size of image can be received. 


<tag-option> := FEh | FFh 
It is possible to include vendor-unique information. 


Definition of Lattice Size 
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<QVGA> := (320 x 240) 


<VGA> := (640 x 480) 
<SVGA> := (800 x 600) 
<XGA> := (1024 x 768) 
<SXGA> := (1280 x 960) 
<FREE>:= (mxn) 


Size is expressed in hexagonal notation by allocating 2 bytes to each of Width and Height. 


Width (2bytes) | Height (2bytes) 


(FFFFh,FFFFh) denotes an arbitrary size, which is used for the appliance that does not need to 
restrict the size, such as printers or PCs. 


Definition of Sampling 


<compressed-420> := C420h 


At the time of WHT0 = "RINE" 


AttValue = <rinf> 
<rinf> := [<tag-mem><memory>][<tag-batt><battery>] 
<tag-mem> := 10h 
<memory> := (the amount of memory available for receiving. FFFFh indicates that the remaining memory 
is large enough. The values other than FFFFh serve as just a rough intimation. Unit is 
Kbytes. 2bytes) 
At default, it is assumed that enough memory is available. 
<tag-batt> := 11h 
<battery> := (the remaining amount of battery. FFFFh indicates that the remaining battery is high enough. 
0000h indicates low battery. Otherwise, it serves as just a rough indication. Unit is 
minute. 2bytes) 
At default, it is assumed, but not assured, that the remaining amount is enough. 


At the time of WHT0 = '"RCMD" 


AttValue = <rcmd> 

<rcmd> := [<tag-opt-func><num-opt-func> { <opt-func>}+] 

<tag-opt-func> := 20h 

<num-opt-func> := (the number of <opt-func>, hexadecimal, 2byte) 

<opt-func> := <func-multi-command> 

<func-multi-command> := 0001h 
The responder can execute a PUT command more than two times while the connection of the 
SCEP layer is established. 
If this parameter is not present in the <opt-func> field, only one command can be executed. 


Default Rule 


1. 


If the reply of Query command is abnormal, (including the case where the Responder has not dealt with 
Query command), it is assumed that the Requester can send a picture with the aspect ratio = 1 : 1, 
<VGA> and <compressed-420>. 

If the reply of Query command is normal, the transmission side searches the optimum transmittable 
form by sequentially reading tags. If there is no transmittable form, it is assumed that the transmission 
side can send <VGA> and <compressed-420>. 


The default rule of each field is noted in the description of each field. 
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When the command execution is abnormally terminated, that is, at the time of the parameter 
AckOrNackFlag of F_Query.rps primitive = Nack, Query_Rpl PDU is configured by setting the parameter 
Result of F_Query.rsp primitive to Attvalue of AttName=”ERRO”. 


AttNum 


0001h ¢The number of Attributes (mandatory) 
(2) 


Attlength | AttType | AFLG | AttValue 


00000004h 


«Result (mandatory) 
¢AttValue is ERRCODE 


(4) 


3.3.2.6.  Put_Req PDU 


Put_Req PDU is configured by setting each parameter of F_Put.req primitive to AttValue : 


FileName : ’ FILO” 
Time : ”’TIMO” 
FileHeader : ”* TYPO” 
Thumbnail : ”°TMBO” 
File : *BDYO”. 


Put_Req PDU is UserData of S_Command.req and S_Command.ind. 


¢The Number of Attributes 


(2) 

AttName | Attlength |AttType]AFLG | AttValue 
“CMDO” )0000006h| 00h 00h 00000000h| 
(4) (4) (1) (1) (4) 

AttName AttType | AFLG 
“ALO ”|Attlength | oi}, 00h a 
(4) 4) a | a 


File Information 


«Command (mandatory) 


*File Name (mandatory) 


*File Information (mandatory) 


3.3.2.7. Put_Rpl PDU 


When the command execution is normally completed, if the parameter AckOrNackFlag is ~Ack’, Put_Rpl 
PDU is configured by setting the parameter “Result’ of F_Put.rsp to AttValue of “BDY0O”. Put_Rpl PDU is 
UserData of S_Command.rsp and S_Command.cnf. 


AttNum ¢The number of Attributes (mandatory) 
(2) 
naire Attlength Aeype BEDS AttValue *Result (mandatory) 
ee (4) on ” (*) AttValue is a stored File N 
alue is a stored File Name 
(4) (1) (1) sc 
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When the command execution is abnormally terminated, if the parameter AckOrNackFlag of F_Put.rps 
primitive is ~Nack’, Put_Rpl PDU is configured by setting the parameter “Result’ of F_Put.rsp to AttValue of 
“ERRO”. 

The scheme of PDU is similar to that of Query_Rpl PDU. 


3.3.2.8. ERRORCODE 
ERRCODE should employ some of the following. 


000 1h: Illegal data received 

0002h: Unsupported PID received 

0010h: Illegal attribute received 

0011h: Unsupported command received 
0020h: File system is full 

0021h: No corresponding file or directory 
0030h: Low Battery error 

003 1h: Abort execution of a command 
0000h: Undefined error 

Others: reserved 


3.3.3. State definition and transitions 


This section contains a state transition table based on the bFTP service primitives described above. 
Descriptions of the states, events and actions are included. 


3.3.3.1. State Transition Table 


The state transition table for bFTP is given below. The first state is NOEXIST. When the action is not 
described, the input event is ignored and the state dose not transit. 


State Transition Table of bFTP 


p—— NOEXIST _|WRSP EXEC 


WRSP_ 
a Ya 
INOEXIST 
EXEC 
_Rpl F_Query.cnf 
a 


Put_Rpl 
INOEXIST 
F_Put.cnf 
NOEXIST 
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3.3.3.2. State Definitions 


The state definition for bFTP is given below. 


States of bFTP 
NOEXIST Not Exist: there is no commad 


Waiting for Reply 
Under Command Execution 


3.3.3.3. Event Descriptions 


The event description for bFTP is given below. 


Input Events 
Request from the upper layer to send Query command 
Response from the upper layer to send the result of Query command execution 
Request from peer to send the Query command 
Response from peer to send the result of Query command execution 
Request from the upper layer to send the Put command 
Response from the upper layer to send the result of Put command execution 
Request from peer to send the Put command 
Response from peer to send the result of Put command execution 


3.3.3.4. Action Description 


The action description for bFTP is given below. 


Output Events 

F_Query.ind Query indication to upper layer 

F_Query.cnf Confirmation of query command execution from peer 
Query_Req Send the Query command to peer 

Query_Rpl Query_Rpl PDU Send the result of command execution to peer 


Put indicate to upper layer 

Confirmation of Put command execution from peer 

Send the Put command to peer 

Put_Rpl PDU Send the result of command execution to peer 
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3.4. IrCOMM and IrLMP IAS Objects 


This section describes the recommendation to use ILCOMM which is one of the reliable data stream. 


The IAS is a database of infrared services, a sort of yellow pages listing what a device can provide. An IAS 
Object consists of a classname and one or more attributes that serve to advertise a service or group of related 
services on a device. 


LsapSel (Link Service Access Point Selecter) is the unique “address” or id of their service within the context 
of one device, and is needed to connect to that service. 


LsapSel attribute of IrDA:IrCOMM IAS entry should be IrDA:TinyTP:LsapSel for the cooed service types 
(3-Wire or 9-Wire). 


InstanceName is used to help distinguish among otherwise idntical IAS objects. Use of this attribute is 


recommended at this document which is IrTran-P. This document recommends to set “IrTran-P” at 
IrDA: IrLMP:InstanceName. 


3.4.1. Recommendation of rCOMM Operation 


1) For category of ITCOMM connection, 9W or 3W of IrCOMM is available. 3W-RAW of IrCOMM is 
unavailable for connections because it does not use TinyTP. 


2) For handling of control signal packets in 9W and 3W, control packets for baud rate setting, signal line 
control and the like are exchanged in addition to data. However, SCEP ignores these control data. 


3) Flow control should be performed by using the credit of TinyTP. 


4) When a packet of SCEP is larger than a packet of IrLAP, segmentation and reassembling of a packet is 
performed between SCEP and IrCOMM. 
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4. 


Notice 
1. 


2: 


4.1. 


4.1.1. 


4.1.2. 


4.1.3. 


This section regards frames as collections of bytes (octets) with each byte being composed of 8 bits numbered 
0-7. Bit 0 is always the least significant bit (LSB) and bit 7 is always the most significant bit (MSB). Bytes 


Appendix Uni Picture Format - 


The specifications of this format are subject to change. 

Version number 

The number of the version of this format is indicated in the following form. 
Version A. BC 

A : Number will increase each time the specification is updated. 


BC : Numbers will increase by one each time a difficulty is cleared up or an 
application rule is updated. 


Introduction 


Scope and Format Abbreviations 


This format is applied to still image data in “IrTran-P”. 
The format name is “Uni Picture Format’, and the abbreviation will be “UPF’. 


Terminology 


The following terms are used throughout this section 


4:2:0 Image component factor and Pixel sampling (see section 4.2.1.1.4) 
APEX Data recording unit for camera setting information (see Appendix A) 
Bit and Byte Ordering 


are represented throughout this section in the following forms. 


Diagrammatic - a byte is represented by a bit number. In some cases bit fields have special meaning and are 
indicated for clarity. The most significant bit is the bit on the left and the least significant bit is the bit on the 


right. An example is given below. 


[MSB] bit7 bit6 bitS bit4 bit3 bit2 bit! bitO [LSB] 


Hexadecimal - a byte is represented with two hex digits with the least significant nibble on the right, the 
most significant nibble on the left, and both digits suffixed by ‘h’. An example is the value 5 which is 


written as O5h. 
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Two bytes form - two bytes represented with four hex digits with the least significant nibble on the right, the 
most significant nibble on the left, and every digits suffixed by ‘h’. An example is the value 256 x 3 = 768 
which is written as 0300h. 


4.1.4. References 


[1] ISO/IEC 10918-1 : “Digital Compression and Coding of Continuous-Tone Still Images”, 
Part 1 : Requirements and Guidelines, 1993 
[2] IEEE EUI-64,”http://standards.ieee.org/db/oui/tutorials/EUI64.html 


4.2. Specifications 


The method of data representation and file structure is defined in this section. Whether the specification is 
mandatory, optional or recommended is also specified. 


4.2.1. Signal format 


The signal format is specified as follows. 


4.2.1.1. Video signal format 


The video signal format and compression method is specified as follows. 


4.2.1.1.1. Pixel aspect 


The pixel aspect ratio of an image is |: 1. Mandatory 
The aspect ratio is the ratio of width to height in an image. 


4.2.1.1.2. Size of index image 


The size of index image in this format is specified as below. 


Horizontal x vertical Name Aspect ratio 
80 x 60 INDEX 4:3 
4.2.1.1.3. Size of image in Query 


The size of image in Query is specified as below. 
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Horizontal x vertical Name 


Aspect ratio 


320 x 240 QVGA 4:3 
640 x 480 VGA 4:3 
800 x 600 SVGA 4:3 
1024 x 768 XGA 4:3 
1280 x 960 SXGA 4:3 
FREE FREE FREE 
4.2.1.1.4. Image component factor and Pixel sampling 


Image components are Y, Cb, Cr of one luminance 


and two color-difference signals. 


Monochrome image is included in the above. 
(See Section 4. 2. 1. 1. 8. 1.) 
The pixel sampling ratio is4:2:0. 
The sampling points of pixel is shown below. 
The line is scanned from left to right and from top to bottom. 


4:2:0 sampling points 


Y Y Y Y Y 

C C C 
Y Y Y Y Y 
Y Y 

C 
Y Y 
Y Y Y Y Y 

C C C 
Y Y Y Y Y 

C:Cb/Cr 
Fig. 4.2.1.1.4 
4.2.1.1.5. Gamma and color management 


Gamma and colors are managed to make color representation possible 


on the below supposed monitor. 


Characteristics of the supposed monitor 
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Mandatory 
Mandatory 


Mandatory 
Mandatory 
Mandatory 


Mandatory 
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1) 


2) 


3) 


4) 


4.2.1.1.6. 


4.2.1.1.7. 


1) 


Gamma is defined using the following reverse characteristics : 


V=1.099L °* - 0.099 1 >=L>=0.018 
V=4.500L 0.018 > L>=0 
L: input V : output of gamma compensation 


Primary chromaticities 


red x = 0.640 y = 0.330 
green x=0.300 y = 0.600 
blue x =0.150 y = 0.060 


x and y are the CIE chromaticity coordinates. 
Chromaticities of reference white 

D65 x=0.3127 y=0.3290 

x and y are the CIE chromaticity coordinates. 


Coefficients of color conversion 


ER 0.299 0.587 0.114 \!f Ey 
EG} = | 0.701 -0.587 -0.114 Er - Ey 
Ep -0.299 -0.587 0.886 Ep - Ey 


Er, Ec and EB are gamma-compensated signals of R,G,B. 
Regarding Ey, Er - Ey and Eg - Ey (see Section 4.2.1.1.7.) 


Number of bits of the image data 


Y, Cb and Cr of the image data are 8 bits. 


Image level 


Y signal 
Y =219(E'y) + 0 
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Mandatory 


Mandatory 
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2) Color difference signal 


Cr = 224 {0.713 (E’r- E'y) } + 128 
Cb = 224 {0.564( E'R-E'y ) } + 128 


that is 


cr=160(E'R -E'y)+128 
Cb=126(E'R -E' y)4+128 


E'y, E' RE 's are gamma-compensated signals of Y, R, B. 
4.2.1.1.8. Image coding method 


Image compression is subject to the JPEG baseline. 
(ISO/IEC 10918-1) 
The index image is subject to the same method. 


4.2.1.1.8.1. Restriction factor of JPEG 


1) Block-interleave only 
2) With a monochrome image, Cb and Cr are compressed as 128. 
3) Huffman table is fixed to JPEG recommended table. 


4.2.1.1.8.2. Definition of MCU 


The block of MCU ( Minimum Coded Unit) is defined as below. 
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Mandatory 
Mandatory 


Mandatory 


Mandatory 


Mandatory 
Mandatory 
Mandatory 


Mandatory 
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MCUO: Yoo, Yor, Yio, Yi1. Cboo. Croo 
MCU1 : Yo2, Yo3, Y12, Y13. Cbor. Cro 


Volvos | | | 


Fig. 4.2. 1.1.8.2 


4.2.2. File Specifications 


A file is specified as below. 


A file name extension must be “UPF’. 


4.2.2.1. File structure 


A file consists of Header Area and Data Area. 

The Data Area consists of single or plural data items. 

The start address of data is defined in Header. 

Data area has to start from an even-number address divisible by 4. 
Data more than 2 bytes is located in most significant byte first. 

The character string is terminated by null (OOh). 

The data used in the Reserved area is 00h when Byte and 0 when Bit. 


The basic structure of a file is shown as below. 


A file has Header Area and Data Area. 
The Header Area size is fixed to 384 Bytes. 
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Mandatory 
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Header 
Area 
(384 Bytes ) 


4.2.2.2. Header organization 


Header is composed of File Header and Entry Area. 


Size 


File Header 240 Bytes 
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4.2.2.2.1. File Header definition 


Field Name Size 


General declaration 


File declaration 


| File declaration 
| Makingdate TB 


0-Reset reserve 


The number of Data entries 
Total number of tables 


Reservel 


Character set code 


Title 


128 


= 


Field definitions 
General declaration 
File declaration 
File ID 
File Version 
Making date 


Editing date 
Maker code, Model code 


Edit Maker code, Model code 


0-Reset reserve 
Numbers of Data entry 


Total number of tables 
Reservel 


“SSS V100” in ASCII 

(Between SSS and V100 is one Space code) 

(see section 4. 2. 3. 2. 1) 

“UPF V100” in ASCII 

(Between UPF and V100 is one Space code) 

(see section 4. 2. 3. 2. 1) 

ID of UPF File : 0x0100 

File Version : 0x0100 

(see section 4. 2. 3. 2. 2) 

Date of making this file (see section 4. 2. 2. 2. 1. 1) 
Date of editing this file (see section 4. 2. 2. 2. 1. 1) 
Code of maker who record this file 

Fill with FFFFh : Not defined 

(Reserved for Maker code, Model code) 

Code of maker who edit this file 

Fill with FFFFh : Not defined 

(Reserved for Maker code, Model code) 

All bytes must be revised to 00h in each modifying 
In initial all bytes are 0Oh 

Total numbers of entries 

Must be 2,3, or 4 

Total numbers of tables 

Reserved : 00h 
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Character set code Character set code of Title 
00h : ASCII 
Olh : ISO-8859-1 
02h : Shifted JIS 
FFh : No existence of Title string 
Other : Reserved 
Title String of Title 
Rest parts are 00h (NULL) 
String must be terminated by 0Oh(NULL) 
Reserve2 Reserved All bytes are 00h 


4.2.2.2.1.1. Date definition 


A date is defined as below. 


Field Name Size Definition 
Difference in time | | Byte Difference in GMT time is expressed by complement 
Unit is 15 minute, from -12H to 12H 


Not defined : 80h 
Christian Era. By binary Not defined : FFFFh 
month by binary Not defined : FFh 
day by binary Not defined : FFh 
our by binary Not defined : FFh 
minute by binary Not defined : FFh 
second by binary Not defined : FFh 


for example + 9h,1997year,6month,26day,20hour,20minute,30second 
: 24h 07CDh 06h 1Ah 14h 14h 1Eh (This example for Tokyo area) 
for example (difference in time part) - [5minute : FFh - lhour : FCh 


4.2.2.2.2. Entry Area structure 


Entry Area has 4 entries. 


Size 


Entry order must be same as data (existing in Data Area) order. 
Each entry has 5 fields. 


Field Name Size 


| Datasize 


Data type ID 


Reserve 
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Field general definition 


Start address 


Data size 


Data type ID 


Reserve 
Information data 


Start address of data 
Address is started from next address of Header end 
(address 0 means 384 Bytes from file top) 
No existence of data : FFFF FFFFh 
Size of data 
0000 0000h : no existence of data 
ID for data type 
OOh : no existence of data 
10h : image 
11h : index image (thumb nail image) 
others : reserved 
00h 
Information of data 
defined in each data type 
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4.2.2.2.3. Entry Area definition 


Field Name Size 


Index image 
data size 


Image 
data size 


Sub data 1 


data size 


Data type ID (Sub data 1) 


information data 
start address 
Sub data 2 

data size 


Data type ID (Sub data 2) 


Reserve4 
Sub data 2 26 
information data 


Field definition 


Index image data Start address of index image 

start address FFFF FFFFh : no existence of index image 
Index image data size Size of index image data 

0000 0000h : no existence of index image data 
Data type ID (index) 11h (fixed) 
00h : no existence of index image 

Reserve 00h 
Index image (See section 4.2.2.2.4.1) 

information data 
Image data Start address of image 

start address FFFF FFFFh : no existence of image 
Image data size Size of image data 


0000 0000h : no existence of image data 
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Data type ID (index) 
Reservel 
Image 

information data 


Sub data | 

start address 
Sub data 1 

data size 
Data type ID (sub data 1) 


Reservel 
Information data 


Sub data 2 

start address 
Sub data 2 

data size 
Data type ID (sub data 2) 


Reserv4 


10h (fixed) 
00h 
(See section 4.2.2.2.4.2) 


Start address of sub data 1| 

FFFF FFFFh : no existence of sub data | 
Size of sub data 1 

0000 0000h : no existence of sub data | 
ID of sub data 1 
OOh : no existence 
00h 
(See section 4.2.2.2.4) 


Start address of sub data 2 

FFFF FFFFh : no existence of sub data 2 
Size of sub data 2 

0000 0000h : no existence of sub data 2 
ID of sub data 2 
OOh : no existence 
00h 


Information data (See section 4.2.2.2.4) 


4.2.2.2.4. Information data definition 


4.2.2.2.4.1. Index image information data 


Field Name Size 


Field definition 


80(horizontal) x 64(vertical) 
(Fill OO50h(horizontal) and fill 0040h(vertical)) 


Image size 
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Image pixel configuration 


00h 


4:2:0 
Olh 4:2:0( orthogonal*) 


*" orthogonal " is when the head of Y and C correspond to the following. 


Horizontal / vertical set of image 


Compression ratio 


White level information 


Type of input device 


Existence of dummy data 


Position in real data 


Non compression ID 


bl, bO —: Information to rotate image 
counter-clockwise 


0 O 0 degree 

0 1 90 degree 

1 O- : 180 degree 

1 1 : 270 degree 

b2 : Information to obtain mirror image 
(Right and left) 

0 : None 

1 : Reverse 


Order of rotation and reversal are rotation as first, 
reversal as next. 


Compression ratio is expressed by number of bits 
in each pixel of picture. 

High position 4 bit : integer part 

Low position 4 bit : decimal part 

Not defined : FFh 


219 or 
FFh : not defined 


FFh Not defined 
First 4 bits lh = Television-related equipment 
Next 4 bits Oh : NTSC lh: PAL 
2h : SECAM 3h: HDTV 
First 4 bits 2h Camera 
Next 4 bits Oh : Original color filter 
1h : Complementary color filter 
First 4 bits 3h = Scanner 
Next 4 bits Oh : Print 

lh : Negative film 

2h : Positive film 


Dummy data is existence (Fill 01h) 


X-BEGIN(=0), Y-BEGZIN(=0) 
(Fill 0000h(X-BEGIN) and fill 0000h(Y-BEGIN)) 


X-SIZE(=80), Y-SIZE(=60) 
(Fill 0050h(X-SIZE) and fill 003Ch(Y-SIZE)) 


00h : JPG (Fill 00h) 
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4.2.2.2.4.2. 


Image information data 


Field Name Size 


| Image size (vertical) 


Type of input device 


2 


Y-SIZE in real data 
Non compression ID 


X-BEGIN in real data 


Reserve2 


Field definition 
Image size Size of image corresponds to number of pixels 
Image pixel configuration 00h 4:2:0 

Olh 4:2:0( orthogonal*) 


*" orthogonal " is when the head of Y and C correspond to the following. 


Horizontal / vertical set of image 1, bO : Information to rotate image 
counter-clockwise 


00 0 degree 

01 90 degree 

10 : 180 degree 

1 1 : 270 degree 

b2 : Information to obtain mirror image 
(Right and left) 

0 : None 

1 : Reverse 


Order of rotation and reversal are rotation as first, 
reversal as next. 
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Wide ID 


Compression ratio 


White level information 


Type of input device 


Existence of dummy data 


Position in real data 


Non compression ID 


Reserve2 


4.2.2.3. Data Area organization 


A Data Area has plural data items. 


00h : normal 

Olh : Cut off top and bottom of picture 
which corresponds to wide mode 

10h : Wide indication of 16:9 in4:3 


Compression ratio is expressed by number of bits 
in each pixel of picture. 

High position 4 bit : integer part 

Low position 4 bit : decimal part 

Not defined : FFh 


219 or 
FFh : not defined 


FFh Not defined 
First 4 bits lh — Television-related equipment 
Next 4 bits Oh : NTSC lh: PAL 
2h : SECAM 3h: HDTV 
First 4 bits 2h Camera 
Next 4 bits Oh : Original color filter 
1h : Complementary color filter 
First 4 bits 3h = Scanner 
Next 4 bits Oh : Print 
lh : Negative film 
2h : Positive film 
Existence / non-existence of dummy data 
OOh : non-existence 
Olh : existence 


Position of real data is expressed by rectangle. 


X-BEGIN, Y-BEGIN 
Start position of horizontal, vertical real 
data ( in pixel units) 


X-SIZE, Y-SIZE 

Size of real data 

Dummy data Content is not defined if dummy 
data non-existent. 

00h : JPEG 

others : reserved 

00h 
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Table data 


Index image data 


Sub data 1 
Sub Data 2 


4.2.2.3.1. Table area structure 


The Table area is composed of several tables. 

The Table area is optional. 

The Table area must begin from Header end with no blank. 
Each table starts from an even-number address divisible by 4. 
The optional blank space between tables are allowed. 

The field data distribution in tables is shown in next section. 
The order of tables is free. 

Every Table has individual ID. 


Table 1 
Table 2 


Table N 


4.2.2.3.2. Table structure 


The table has 3 fields shown as below. 


Field Name Size 


Table ID 
Next table pointer 


Table data free 
(max.254) 


Field definition 


Table ID Type of Table 
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Next table pointer The Next table pointer is table size minus 2. 
(In this case, table size includes the following blank area.) 
The Next table pointer in the last table is also table size 
minus 2. 


The basic addressing of tables is shown as below. 


Start address Table data name data 


Table ID [oe 
mtn 


1+1 Next table 
pointer 


l+m+2 Blank 
(n Bytes) 


Next Table ID 


1+2 Table data 
(m Bytes) 


4.2.2.3.3. Types of table 
Table type ID See Section number 
Comment table 12h 4.2.2.3.4.1 
Author information table 13h 4.2.2.3.4.2 
Camera information table 24h 4.2.2.3.4.3 
Transfer URL information table 80h 4.2.2.3.4.4 
Transfer TEL information table 81h 4.2.2.3.4.5 
Optional table 90h 4.2.2.3.4.6 


All IDs except the above are reserved. 


4.2.2.3.4. Table definition 


Tables are defined as follows. 


4.2.2.3.4.1. Comment table 


Field Name Size 


Table ID (12h) 
Next table pointer 


Field definitions 
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Character set code 00h : ASCII 
Olh : ISO-8859-1 
02h : Shifted JIS 
other : Reserved 
Comment Comment is recorded. 
Maximum 252 bytes including last code of 00h 


4.2.2.3.4.2. Author information table 


Field Name Size 


itor i 


Editor information 


Field definitions 


Character set code 00h : ASCII 
Olh : ISO-8859-1 
02h : Shifted JIS 
Other : Reserved 
Author and editor information are optional. Last code is 00h. 


4.2.2.3.4.3. Camera information table 


Field Name Size 


1 
Aperture 


Reserved 


Field definitions 


Shutter speed APEX unit 1/100 unit 2’s complement 
Aperture APEX unit 1/100 unit 2’s complement 
Brightness APEX unit 1/100 unit 2’s complement 
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Exposure Bias APEX unit 1/100 unit 2’s complement 
Max. Aperture Ratio APEX unit 1/100 unit 2’s complement 
8000h = Unidentified in the above 
APEX unit (see Appendix A) 


Focal Length 1/10 mm unit FFFFh: Unidentified 
Subject Distance 1/10m unit FFFEh : Infinite 
FFFFh : Unidentified 
Metering Mode OOh: Average Olh: Center Weighted Average 
02h : Spot 03h : MultiSpot 
FFh : Unidentified 
Light Source 00h: Daylight Olh: Fluorescent light 


02h : Tungsten Lamp 


10h : Standard light source A 
11h: Standard light source B 
12h : Standard light source C 
20h : D55 21h: D65 
22h : D75 
FFh : Not defined 

Flash 00h : No flash 
Olh : Flash 
FFh : Not defined 

Interval information Time of interval when continuous recording or recording at 
interval 
bit 15 ~ bit 14 reserved 


bit13~bit12 0 0) 1/1000 seconds 
0 1 second 
1 0) minute 
1 1 hour 


bit 11 ~ bit O Data of interval 
FFFFh : Not defined 


4.2.2.3.4.4. Transfer URL information table 


Field Name Size 


Transfer URL information 


Field definitions 


Character set code 00h : ASCII 
Olh : ISO-8859-1 
02h : Shifted JIS 
Other : Reserved 


URL Address for transfer is recorded as follows. 


URL address for transfer <URL>url address information 
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for example <URL> http://www.urladdress.co.jp/index.html 
for example <URL> ftp://ftp.ftpaddress.co.jp/file.exe 
for example <URL> file:///C\/diskdir/file html 
for example <URL>mailto:mailaddress @ aaa.bbb.co.jp 
Last code of 00h 


URL address is recorded by using absolute address and based on 
the HTML 3.2. 
Maximum length of transfer URL information table is 252 bytes. 


4.2.2.3.4.5. Transfer TEL information table 


Field Name Size 


Table ID (81h) 
Next table pointer 


Transfer TEL information 


Field definitions 


Character set code 00h : ASCII 
Other : Reserved 


Telephone number or FAX number for transfer is recorded as follows. 


Telephone number for transfer <TEL>telephone number recorded 
by +,-(minus),0 to 9 
for example <TEL>+81-3-1234-1234 
for example <TEL>03- 1234-1234 
Last code is 00h 


Fax number for transfer <FAX>Fax number recorded by +,-,0 to 9 


for example <FAX>+81-3-1234-1234 
for example <FAX>03-1234-1234 
Last code is 00h 


Total maximum length of transfer TEL information table is 252 bytes 
which includes at least one <TEL> or one <FAX>. 
Transfer TEL information table includes only one<TEL> or one <FAX>. 


4.2.2.3.4.6. Optional table 
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Field Name Size 


Model code 
Maker code 2 


Reserve 1 


Optional data 


Field definitions 


Maker code Fill with FFFFh : Not defined 
(Reserved for Maker code) 

Model code Fill with FFFFh : Not defined. 
(Reserved for Model code) 

Maker code 2 Fill with EUI-64 company_id code 

Reserve 00h 

Optional data Optional data less than 246 bytes 

4.2.2.3.5. Main data structure 


Plural data in Data Area are shown as below. 


Index image data and Image data are compressed by JPEG baseline. Mandatory 


4.2.3. Application rule 


In order to ensure the system’s interchangeability, the following rules are established. 


4.2.3.1. Signal format matter 


4.2.3.1.1. Image compression method 


In Uni Picture Format , image data is compressed by JPEG baseline. 
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JPEG compression is made by 8 x 8 block . 
Original information of the color difference signal of Cr, Cb is as follows: 


4:2:0 16 x 16 
However, if the image data cannot be divided by the above block ratio, dummy data is added 


and compression is performed. 
Dummy data are inserted at the right side of the line and the bottom of the image 


4.2.3.1.2. Marker Segments 


In addition to entropy data, compressed data include marker segments for SOILEOILSOF,SOS, 
APPO to APP15,DHT,DQT. Table 4.2.3.1.2 shows Marker Segments used in Uni Picture Format. 


Table 4. 2.3.1.2 | Marker Segments 


[—[Makernane ‘(| Maker Code 


Start of Image Start of compressed data 

End of Image End of entropy coded data 

Start of Frame Various parameters related to a frame 

Start of Scan Various parameters related to a components 


Application Segment 14 Information of Uni Picture Format 
Define Huffman Table Huffman table 
Define Quantization Table Quantization table 


4.2.3.1.3. Information of Uni Picture Format Recommended 


Field Name Size 


Field length 
| Information dT 


free 
(max64K-12) 


Field definition 


APP14 Marker FFEEh 
Field length maxsize less than 64K bytes. 
(Field length should be kept small size. About 20h or 30h) 
Information “UPF V 100” 
(Between UPF and V100 is one space code in ASCID 
data Free data 
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4.2.3.2. File management matter 
4.2.3.2.1. Management of declaration 


The declaration of file (see 4. 2. 2. 2. 1) is available for rejecting another file. 


General declaration : “SSS 

File declaration : “UPP”’ 
In each declaration, first 3 Bytes (see ahead) are available for this use. 
Rest each 5 Bytes must be ignored. 


4.2.3.2.2. Management of File version 


The File version (see 4. 2. 2. 2. 1) is used for version up. 
upper byte : shows integer part , if this byte is changed there is no interchangeability 
from old version. 
lower byte : shows decimal part 
First 4 bits : inclement when feature is updated 
Next 4 bits : inclement when minor change is done with keeping 
interchangeability 
for example Ver 1.12: 01h 12h Ver 1.26: Olh 26h 


4.3. Additions 
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Appendix A : Data recording unit for camera setting information (APEX) 


Uni Picture format uses a unit for camera setting information called “APEX” (Additive System of 
Photographic Exposure). APEX is a convenient unit for calculating the exposure value : Ev. 
The relationship between the conventional unit and the APEX unit is as follows. 


Aperture V alue(Av) = 2log>(FNumber) 
ShutterS peedValue(Tv) = -log,(ExposureTime) 
Brightness Value(Bv) 7 log>(B/NK) 


B:cd/m’, N,K:constant 
The speed Value is as follows. 
Speed Value(Sv) = logo(ASA/3.125) 
The exposure value is calculated as follows. 


Ev = Av + Tv = Bv+ Sv 


Brightness Value Foot lambert 
(APEX) 


1 /2 


- 1 
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Shutter Speed Value Exposure Time 
(second) 


30 


1/2 
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